Miracast is an interoperability program, based on the WiFi Alliance's WiFi Display (WFD) specification, that allows products to provide seamless wireless display of content, including video, audio and graphical content, across WiFi devices (i.e., IEEE 802.11-compliant devices, such as IEEE 802.11ac devices). In particular, a Miracast “source device” provides content which is displayed, via a wireless link, at a Miracast “sink device,” without either device necessarily connecting to a WiFi network. By utilizing WiFi capabilities to form a direct wireless connection, the source device (e.g., a laptop, smartphone, etc.) can take advantage of better display capabilities of a sink device (e.g., a digital television, audio/video receiver, etc.) to display content that is initially stored in, or streamed to, the source device.
The rate at which raw video data must be sent for seamless display is very large. At a high-definition resolution of 1920×1080, with 60 frames per second, 8-bit depth, and a 4:2:0 chroma format, for example, the raw data is nearly 1500 megabits per second (Mbps). To transfer such a large amount of video data over the wireless connection, WFD compresses the data using H.264 video compression. In conjunction with advanced coding techniques, the H.264 video encoder can achieve better than a 100:1 compression ratio.
To achieve this high compression ratio, the H.264 video encoder utilizes both spatial and temporal compression in order to reduce redundancy in the video data. In particular, the H.264 video encoder divides a video frame into a string of “macroblocks” that each correspond to a block of 16×16 pixels within the video frame. Moreover, the H.264 video encoder generates two different types of frames (or “slices”): “I-frames” and “P-frames.” Each I-frame corresponds to a first video frame in a “Group of Pictures” (GOP), where the GOP may include approximately 10 to 20 successive video frames. I-frames utilize spatial compression, with macroblocks of an I-frame utilizing other macroblocks within the same I-frame as “reference” macroblocks. That is, compressed data representing a first macroblock of an I-frame may represent differences between the first macroblock and a second macroblock of the same I-frame, rather than completely and independently describing the first macroblock. P-frames also utilize temporal compression, with macroblocks of a P-frame utilizing corresponding macroblocks of an earlier I-frame (within the same GOP as the P-frame) as reference macroblocks. That is, compressed data representing a macroblock within a P-frame may represent differences between the P-frame macroblock and the corresponding macroblock within the (earlier) I-frame, rather than completely and independently describing the P-frame macroblock.
Because the decoding of compressed video data for macroblocks is largely dependent on the successful decoding of other compressed video data for other, reference macroblocks, H.264-encoded video data is very sensitive to data corruption. This sensitivity is exacerbated by the fact that the H.264 video encoder uses variable length coding (VLC), without marking the divisions between macroblocks in the compressed video data. As a result, if a WiFi packet carrying a portion of a video frame is lost, the rest of the video frame is generally not decodable regardless of whether the corresponding video data is received correctly. In conventional WFD systems, loss or corruption of an I-frame causes a very substantial degradation of the viewer's user experience (e.g., the video may freeze or disappear at the sink device until a new I-frame of a new GOP is received), while loss or corruption of a P-frame causes bothersome artifacts that can also detract from the viewer's user experience (e.g., “blips” or “blobs” in the video that persist until a new I-frame of a new GOP is received).
Further, the source-to-sink WiFi links utilized for WFD often have a relatively high bit error rate. Because a large number of WiFi packets (e.g., more than ten WiFi packets for 1920×1080 resolution) is typically needed to send a single H.264-encoded video frame, errors in the various I-frames and P-frames are likely. While a WiFi packet may be re-transmitted if no acknowledgement is received from the sink device, the packet will be dropped by the source device if no acknowledgement is received after several re-transmissions. Moreover, WFD uses the User Datagram Protocol (UDP), which does not guarantee reliable data delivery.
The relatively poor reliability of WiFi links, combined with the high sensitivity to data corruption for H.264-encoded video data, can significantly degrade the user experience when viewing video content displayed by a Miracast sink device. Conventional “packet loss concealment” (PLC) techniques, which are implemented at the sink device, have had very limited effectiveness.